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Abstract 


TIh' prurt'ss of r<‘«‘ugin<‘<‘riiig involves examination and alteration of an exist- 
ing system in t»r<l«*r to arrive at a new form, and a subsequent implementation 
tif the new funn. One sudi problem, addressed here, is migrating the exist- 
ing file i>a.sed systems implemented in COBOL to a relational environment. 
W'e liave tb'signed and implemented a workbench, SQLC, which automates 
this task to the extent possible. The subject system is re-engineered in three 
phases using SQLC. In the first two phases data model is recovered and con- 
verted to relational database, and in the final phase COBOL programs are 
r«'stru<-tured to Cl with embedded SQL. In this thesis, we shall discuss the 
eum eplual framework used in re-engineering COBOL programs to C with 
einbe<i<ie<l SCJL. 
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Chapter 1 


Introduction 


1.1 Motivation 

Most of the earlier information systems were implemented in COBOL. 
COBOL has been widely used because it has good file handling facilities. 
Here, the data is stored in files supported by the operating system. The 
main limitation of these systems is that they lack a single integrated data 
view. The relationship between various data items is implicitly imp le y 
the processing actions of the programs. This results i» data ledundancy an 

difficulty in the maintenance of COBOL programs. 

Data semantics, data consistency, data constraints and the re ations ip 
between various data items or data records, can be represented y a ata 
model, a'he three important available data models are relational, network 
and hierardiical. The relational model is more successful model than t e 
other two models. 

An RDBMS environment supports a variety of functions that have to 
be coded explicitly in COBOL. Adhoc query support eliminates the need to 
write a separate program. A report generator can replace co e t at exp ic 
itly formats the output report. Other useful features inc ude security, a a 

integrity, roll back, crash recovery etc. . 

The maintenance of the information systems implemente in 
consumes most of the MIS resources. But they are still being continue as a 
lot of money has already been invested in them. It is becoming increasing y 
desirable to migrate these information systems to a re ationa p a orm, so 
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that the fcattircs available in an RDBMS environment can be extended to it 
and maintenance costs can be cut down. After migration, as all the file access 
statements are handled by RDBMS, there is no need to stick to COBOL. C 
language would be better as it i.s quite popular. The task of migration of a 
subject system to an RDBMS environment and the translation of a source 
program comes under the purview of re-engineering. 


1.2 Problem definition 

'rhe aim of this project is to develop a workbench which provides an envi- 
ronment to re-engiiH'cr existing file based systems implemented in COBOL 
to an Ingres relational platform. 'I'his involves recovering data model of the 
.subj«‘ct sysl<‘m and converting it to a relational database, and transforming 
the (’OBOL ])rograms info C with embedded SQL. 


1.3 Related work 

'I'his problem ha.s attracted wide attention. We list some of the tools devel- 
oped in this regard. 

• Ibdine is a workbench that supports following features in working with 
COBOL legacy systems: 

- Aids in understanding code structure. 

- (»en<'rat<*s docnm<‘ntation. 

- Aids in as.sessing and improving code quality. 

• P. L. Srinivas at IIT Kanpur developed COBSQL [1], a tool that trans- 
forms the COBOL programs into programs which accesses a relational 
database. This involves replacing all file access statements by equiva- 
lent SQL statements. 

• Lately, work has been going on, on a project COBCY for the develop- 
ment of a compiler that transforms COBOL programs into C programs 
[2]. But, it is still in an embryonic stage. 
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1.4 Work done 


In the present work we have removed some of the limitations of COBSQL and 
implemented a workbench named SQLC that migrates COBOL programs to 
an RDBMS environment. SQLC migrates COBOL programs to the target 
environment in three phases - Parsing, Unification and Conversion. 

• Parsing: A grammar based tool is used to extract the data view as 
seen by each program [3]. 

• Ihiijication: A tool named Unifier is used to unify the the extracted 
data views to a single integrated data view. The recovered data model 
i.s represented in an intermediate form which is used in a later phase 
[3]. 

• Conversion: A grammar based tool named Converter is used to restruc- 
ture COBOL programs into C with embedded SQL. Converter takes a 
COBOL program and the recovered data model as input and outputs 
C with embedded SQL. 


1,5 Organization of the thesis 

The rest of the report is organized as follows 

• Chapter 2 outlines the main features of COBOL. 

• Chapter 3 presents an overview of data management in the target 
environment. 

• Chapter 4 outlines various phases in migration of COBOL programs 
to RDBMS environment and also describes the various rules used in 
restructuring COBOL programs to C with embedded SQL. 

• Chapter 5 presents an overview of the various tools provided by 

SQLC. 

• Chapter 6 evaluates the characteristics of the re-engineered system 
and also outlines the test suite followed to test the restructuring rules. 
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• Chapter 7 summarizes the work done and suggests extensions to the 
project. 


4 



Chapter 2 

Source environment: COBOL 
and flat file 


In this chapter we outline the main features of COBOL which are relevant 
to our present work (Phillipakis and Kajmier [4], Dastidar [5]). 

2.1 Data types 

In this section we describe briefly the main data types supported by 
COBOL. 

2.1.1 Elementary data types 

The eUnnentary data types supported by COBOL arc numeric, alphanumeric, 
alphabetic, numeric edited and alphanumeric edited. They are discussed 
briefly here. 

• NumericiA numeric data item is used to store a number. A data item 
is said to be of numeric type, if its picture class description has only 
the following symbols - 9, P, S and V. 

• Alphabetic: An alphabetic data item is used to store characters. A data 
item is said to be of alphabetic type, if its picture class description has 
only the following symbols - A and B. 
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• Alphanumeric: An alphanumeric data item is used to store a number 
or characters. A data item is said to be of alphanumeric type, if its 
picture class description has only the following symbols - 9, X and A. 

• Numeric edited: A numeric edited data item is used to store a number. 

When data is moved to this data item, the value gets edited according 
to the specification made in its picture class description. A data item 
is said to be of numeric edited type, if its its picture class description 
has the following symbols - B, /, Z, 0, 4, *, „ CR, DB, and $. 

• Alphanumeric cdit<d: An alphanumeric data item is used to store a 
number or characters. When data is moved to this data item, the 
value g<‘ts editetl according to the specification made in its picture class 
descrij>tk)n. A data item is said to be an alphanumeric edited type, if 
its picture class description has the following symbols - X, 9, A, B, 0, 
and /. 

Condition name 

A Condition name is associated with a variable and specifies either a single 
or a set of values for the same. 

For example, 

77 DEGRFK-TYPE. 

88 B-TECii VALUE IS ONE. 

88 M-TKCH VALUE IS TWO. 

In the above example, B-TECH and M-TECH are Condition names associ- 
ated with the variable DEGREE-TYPE. 

2.1.2 Group item 

A group item is made up of fields which are either elementary or again group 
items, resulting in a tree like structui'e. This structure is described in COBOL 
using level numbers. 


For example 
01 CARD. 



02 NAME PICTURE IS X(25). 
02 STREET PICTURE IS X(25). 
02 CITY PICTURE IS X(30). 


2.1.3 Table 

A table is a list of similar data items. It eliminates the need for separate 
entries for repeated data items. 

for example, 

01 SALES OCCURS 4 TIMES PICTURE IS 99999. 

2.1.4 File 

In COBOL, a file i.s treated a.s a sequence of records. COBOL supports three 
types of file organizations namely sequential, relative and indexed. A file can 
be accessed in one of the three modes - sequential, random or dynamic. In 
dynamic mode, a file can be accessed either sequentially or randomly. 

In the sequential file organization, records are stored in the same order 
they are written in. Also, records can be accessed only in the order in which 
they arc stored in the file. 

In the relative file organization, records are identified by a relative record 
nuniber. The relative record number specifies the location of the record from 
the beginning of the file. This file can be accessed in three different modes 
namely sequential, random or dynamic. For the random mode, one has to 
specify the relative record number. 

In the indexed sequential file organization, the file is organized on its 
primary key field. Records are stored in either ascending or descending order 
of the key. This file too can be accessed in any of the three different modes 
mentioned before. For the random mode, one has to specify value of the key. 


2.2 Program structure 

Every COBOL program consists of a set of instructions. This set is divided 
into four divisions namely Identification division. Environment division. Data 
division and Procedure division. 
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Identification division is the first division of every COBOL program and 
is used for documentation purposes. In our context this division is relatively 
unimportant. 

Environment division specifies details of the computer and all the pe- 
ripherals used by the program. It has two sections namely Configuration 
section and Input-output section. The Configuration section contains an 
overall specification of the computer used for the purpose of compilation and 
execution of the program. The Input-output section specifies all the files 
used by the program and the type of hardw'are required for each file. 

Data division gives a detailed description of every data item used in the 
program. It has four sections namely File section, Working Storage section, 
Linkage section, and Report section. File section provides a detailed speci- 
fication of the structure for each file used in the program. Working storage 
section is used to describe the data items which hold intermediate results in 
processing. Linkage section specifies declarations of the data items used in 
communicating with subroutines. Report section is used to describe the data 
items used for generating reports. 

Procedure division consists of statements which specify processing actions 
on the data items declared in the Data division. 


2.3 Control flow 

Procedure division of a COBOL program is composed of one or more para- 
graphs. A paragraph is the basic unit of processing. Under the rules of 
COBOL, a paragraph can be executed in any of the three ways as described 
below: 

1. By Perform statement. 

For example, 

PERFORM READING-RECORDS. 

This statement causes control to be transferred to the paragraph 
READING-RECORDS. After the execution of paragraph READING- 
RECORDS, control returns to the statement lexically following the 
Perform statement. 
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2. By Goto statement. 

For example, 

GO TO ERBOR-PARA. 

Thi.s statement transfers control to the paragraph ERROR-PARA, with 
no return at the end of that paragraph. 

3. A paragraph ran be executed as a result of fall thru. This will result, 
when the cxecut ion of a paragraph reaches the end of it and has not 
been called by P<’rfonn staleinent. At this point control passes to the 
paragraph which lexically follows the current paragraph. 

2.4 Subroutine 

In COBOL a siibroulinc has USING phrase in the header of Procedure divi- 
sion. The general syntax for Procedure division of subroutine is - 

PROCEDURE DIVISION USING data-name-l [,data-name-2] ... 

The data-name-l, data- name-2 etc are described in the Linkage section of 
the program. A subroutine can be executed by a Call statement. The Call 
stat<‘m(Mit transf<;rs control from the calling program to the subroutine. It 
also copies the vahic of data items in the Call statement to the correspond- 
ing data items in the procedure division header of the subroutine. After 
execution of the subroutine, values of the data items specified in its USING 
phrase ar<* copied back to the corresponding data items specified in the Call 
statement of the calling program. 
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Chapter 3 


Target environment: Relational 
database and SQL 

In this chapter we present an overview of data management in the target 
environment [6]. 

3.1 Relational database 

In a relational database relationships among the data are represented by 
tables. A table i.s a two dimensional structure with rows and columns . A 
row in the table repr<*sents a relationship between the set of values. Each 
row in the table is uniquely identified by the value of the primary key. 


3.2 Query languages 

Query languages are used to access data from the relational database. These 
languages are at a higher level than application programming languages like 
C. The three important query languages available are SQL, Quel and QBE. 
SQL is the most widely used query language. 


3.2.1 SQL 

The SQL provides following features: 
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• Data drfiniiion language: The SQL data definition language provides 
commands for defining tables and views, deleting tables and modifying 
tables. 

• Data manipulation language: The SQL data manipulation language 
provides commands to manij)ulate data stored in the relational database. 

• Embedded SQL statements: Application programs can access the data 
stored in the relational database through SQL statements embedded in 
it. 

• Inifgriiy and Stciirity: The SQL includes commands to specify be- 
gin and «Mi<l of transactions. It also provides commands to specify 
integrity <Mnstraints and integrity checking on data stored in the rela- 
tional dal abase. 


3.3 C application program interface 

A C program <an access the relational database through embedded SQL 
statements. These commands are used to declare host variables, to define 
cursor, to manipulate cursor and table and to include code for error handling. 

3.3.1 Host variable 

In C with emb<‘dded SQL, data transfer between an object program and a 
database is done through host variables. Host variables can be of three types 
nam<‘ly inU'ger, float and char. 

3.3.2 Data manipulation 

Embedded SQL provides the following SQL commands to manipulate data 
stored in the table. 

• Select, returns one or more rows from the specified table. 

• Insert, adds new rows into the specified table. 

• Delete, deletes one or more rows from the specified table. 
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• Update, changes the data in one or more columns of the specified table. 


3.3.3 Cursor 

A cursor is a pointer to individual rows in a SQL query result. Embedded 
SQL supports the following SQL commands to manipulate the cursor. 

• I)<‘flare, used to define the cursor. 

• Oix'ii, used to determine the set of rows pointed by tlie cursor and 
allocate memory for them. 

• I'Vteli, ('oi>i<'s the* eontc’iits of a row into the specified liost variables and 
advance.s the* position of Ihc' opened cur.sor to the next row. 

• Update*, u.sc'd to njxlatc* value's of the current row of the specified cursor. 

• Close*, used to free the memory allocated to handle the cursor. 
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Chapter 4 


Re-engineering from COBOL 
to SQL and C 


'I’his chapter outlines the various phases in re-engineering and enumerates 
(he rules us('<i to n'structure C'OBOL programs to C willi embedded. 


4.1 Phases in Re-engineering 

The <>xisling systems iinphnnonted in COBOL are rc-cngineered to a re- 
latitmal environment in tlir<‘e phases namely Parsing, Unification and Con- 
v<-rsi()n. In the first two jdiases, we rc-onginecr the data model. The subject 
syst<'m does not have an int.c'grated view of data because the data view as 
s<’(Mi by t'ach program may he different. The various conflicts that can occur 
!»<‘t\v<‘en the different data vi<‘ws of programs are listed below 

1 . The same data item has different structures in different programs. This 
is because the programmer describes only those data items which he 
wants to refer and declares the rest of them as FILLER. 

2. The same file or record or data item is declared by different names 
in diff(‘rcnt i)rograins. This is due to not following a uniform naming 
convention. 

3. The same data item is defined by different types in different programs. 
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So, tlip nictliodology adopted in re-engineering data model is to extract 
th<* data view as st'en by eacli j)rogram and unify these views by an unifying 
algorithm [3]. The unified view is represented in an intermediate form named 
Unydi'f which is used in a later jihase. Unydef provides correspondence in- 
formation between the record fields of the file and the fields of the table. The 
Unydef is explained below by an example. 

The meanings for the various symbols used in representing the data model 
ar<‘: 

s: I'iehl type is char 

k: K<*y fi<‘l<l 

n: Not a key field 

c: Nanx' for lh<' liehi is i hangi'd 

u: Name for the field is unchanged 

r: Hecord field is unified to more than one table field. 

In further discussion, we refer to the.se table fields as sub- fields. 

'fhe data view as seen by program A for the file CARD-REC is: 
CARD,.NAME s lb k.' 

CARD-UOUSE-NOs 10 n, 

FILLER .1 s 55 n 


'fin* data view as seen by program B for the file CARD-REC is: 
<1AH1)..NAMK s 25 k,' 

FULLER. 1 s 10 n, 

CAHl).B'rHKKT s 25 n, 

CARD.CITY s 30 n 

After unification, the recovered relation for the file CARD-REC is: 
CARDJ^AME s 25 k, 

CARD_HOUSE.NO s 10 n, 

CARD^STREET s 25 n, 

CARD.CITY s 30 n. 

Then Unydef for the file CARD-REC in program A is: 
CARD.NAME s 25 u, 

CAKl).HOUSE_NO s 10 u, 
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FlLLKK.l r { 

(^AHI).STHKET s 25 u, 

CARD.C.ITY s 30 u 

} 

I’nydcf for the fil<* OARD-KEC in program B is; 

CAHD-NAMK s 25 u, 

CAHDJIOUSK.NO s 10 u, 

CAKD-STRE ET s 25 u. 

FU.LER l .s30 r (’ARIXCriT 

In (h<‘ final phase, using r<'sl met nring rules we transform (.'OBOl^ programs 
into ( ’ with enihe<i(i<-«l. 


4.2 Restnictiiring rules 

In this seeticMi we enumerate restructuring rules for the main features of 
COBOL. 


4.2.1 Data names 

% 

In (’OBOE names of data item are formed only with following characters: 
0 i),A Z an<l 

'Elie conversion rule for <lata names is: 

R<‘plare tlu' character with character COBOL data names are not 
ca.s<‘ stmsitive. We take this feature as advantage in forming names for new 
variables which are used to simulate .semantics of COBOL. 

4.2.2 Data types 

Elementary data types 

The elenu’ntary data types supported by COBOL are numeric, alphanumeric, 
alphabetic, numeric edited, alphanumeric edited. 

Data items of numeric t 3 'pc arc converted to either integer or float tj^pe. 

For example, 


15 



01 NO-OF-RECORDS PICTURE IS 999. 

01 MARKS PICTURE IS 999V99. 

The above declarations are replaced with 
int NO-OF-RECORDS; 
float MARKS; 

Data items of alphanumeric, alphabetic, numeric edited, alphanumeric 
edited type are converted to char type. 

For example, 

01 NAME PICTURE IS X{25). 

The above declaration is replaced with 
char NAME[25 + 1]: 

Condition name 

A Condition name is converted to a function which checks whether the vari- 
able to which it is associated is within the specified range. 

For example, 

77 DEGREE-TYPE. 

88 M-TECH VALUE IS ONE. 

The above declaration for the Condition name M-TECH is replaced with 
int M.TECHO { 

if( DEGREE.TYPE == ONE) 
return TRUE; 
else 

return FALSE; 

} 

Group item 

The group items declared in Working Storage section are converted to struc- 
tures. 

For example, 

01 BALANCE-DATA. 

02 ITEM-NUMBER PICTURE IS 99999. 

02 PART-NUMBER PICTURE IS X(14). 
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02 ITEM-NAME PICTURE IS 99999. 

The above declaration is replaced with 
struct { 

int ITEM.NUMBER; 

char PART_NUMBER[14 4- 1]; 

int ITEMJs’AME; 

}BALANCEJDATA; 

Table 

Table data items are converted to arrays. 

For example, 

01 SALES 0(X."UHS 4 TIMES PICTURE IS 99999. 

'Lhe above declaration is replaced with 
int sales[4]; 

File 

A file is converted to a table. In COBOL, data transfer between files and 
object program is done through records described in the File division. In C 
with embedded SQL, it is done through host variables. Record fields declared 
in the File section are replaced with host variables. The name of the host 
variable is formed by concatenating the names of all top level data items 
to the name of the corresponding record field. This is necessary, because in 
COBOL the name of the record field need not be unique as record structure 
is tree like and can be qualified by top level data items. But in relational 
database the structure of the table is flat. This means name for every host 
variable must be unique. 

For example, 

01 CARD. 

02 NAME PICTURE IS X(25). 

02 STREET PICTURE IS X{25). 

02 CITY PICTURE IS X(30). 

The above declarations are replaced with 
EXEC SQL begin declare section; 
char CARD-NAME[25 + 1); 
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char CARD^TREET[25 + 1]; 
char CARD.C1TY[30 + 1]; 

EXEC SQL end declare section; 

Unification results in a single integrated view of data. Due to this a record 
field can be unified to more than one field of the table. If this happens, we 
have to declare host variables for sub-fields. This may result in name clashes 
while declaring host variables. One can avoid the name clash problem by 
concatenating sub-fidd name with SqlC-#NO, where #N0 is unique for 
every field. 

For examph', 

Th<‘ file d('scriptit>n for the file CARD-HEC is 
01 CARD. 

02 ADDRESS PICTURE IS X(80). 

Let Unydef for the file CARD-REC is 
ADDRESS r { 

CARD_NAME s 25, 

CARD. STREET s 25, 

CARD-CITY s 30, 

} 

Then host variable d<'clarations for the file CARD-REC are 
EX PIC SQL begin declare section; 
char CARD.ADDRESS-1[80 + 1]; 
char CARD.NAMP:SqlCl[25 + 1); 
char CARDJ>THEP:'J'SqlC2[25 + 1]; 
char CAKD.CJTYSqlC3[30 + 1]; 

EXEC SQL end declare section; 

4.2.3 Arithmetic operators 

There are five binary arithmetic operators in COBOL. Operators +, -, * 
and / mean addition, subtraction, multiplication and division respectively. 
These operators need not be replaced as they are supported by C language. 
Operator ** stands for exponential. This operator is replaced with pow(...) 
a library function, as it is not available in C language. 

For example, 2**3 is replaced with pow'(2,3); 
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4.2.4 Conditions 


In COBOL conditions arc categorised as Relation condition, Sign condition, 
Class condition, Condition name condition, Negated simple condition and 
Compound condition. 

Relation condition 

Tlie Relation condition specifie.s comparison of two operands. 

I'he conver.sion rules for the Relation condition are: 

• Format 1: 

oi>erand-l IS ■{ 

CtHK.‘\THH TH.AN 1 > 

1 LRSS TH.'\N i < 

1 EQUAL TO 1 = 

} operand-2 

If operands are of numeric type then the conversion rule for the above 
format is 
operand- 1 { 

!>!> 

i-H - 

} operand-2 

If op<*rands are of non-numeric type then the conversion rule for the 
above format is 
{ 

strcmp(operand-l, operand-2) > 0 ] 
strcnip(operand-l, operand-2) > 0 1 
strcmp(operand-l, operand-2) < 0 | 
strcmp(operand-l, operand-2) < 0 | 
strcnip(operand-l, operand-2) == 0 j 
strcmp(operand-l, operand-2) == 0 | 

} 


• Format 2: 
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operand- 1 IS NOT { 

1 GREATER THAN j > 

! LESS THAN 1 < 

1 EQUAL TO 1 = 

} operand- 2 

If operands are of numeric type then the conversion rule for the above 
format is 
operand- 1 ■{ 

!<=!<= 

1 >- 1 >= 

1!= 1!= 

} op<‘rand-‘2 

if operaiuls are of non-numeric type then the conversion rule for the 
al)Ove format is 
{ 

strcinp{operaiKl-L operand-2) <= 0 | 
st rcmp( operand- 1, operand-2) <= 0 [ 
strcinp(operand-l, operand-2) >= 0 | 
strcmp(oi>crand-l, opcrand-2) >= [ 
sf rcnip(op<‘rand-l , operand-2) != 0 | 
strcinp(oi>erand-l, operand-2) != 0 | 

} 

Sign condition 

The Sign condition evaluates whether the value of an arithmetic expression 
is less than, greater than or equal to zero. 

The conversion rules for the Sign condition are: 

• Format 1: 

arithmetic-expression IS {POSITIVE | NEGATIVE | ZERO } 
is replaced with 

arithmetic-expression { > 0 | < 0 j == 0 } 

• Format 2: 

arithmetic-expression IS 
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NOT {POSITIVE I NEGATIVE | ZERO } 
is replaced with 

arithmetic-expression { <= 0 | >= 0 | != 0 } 

Class condition 

The Class condition determines the type of operand. 

The conversion rules for the Class condition are: 

• Forme/ / : 

operand IS [ NOT } ALPHABETIC 
is replaced with 
/!/IsAlphaS(jlC(operand) 

W})<T<‘ Is.MphsSqK'O is a library function which tests whether operand 
is of alphabetic type. 

• Format 2: 

operand IS / NOT } NUMERIC 
is replaced with 
/! yisNuniericSqlC(operand) 

Where IsNumericScjlC() is a library function which tests whether 
operand is of numeric type. 

Condition name condition 

The (^osidition nanu' condition evaluates whether the variable to which Con- 
dition name is a.ssociated, is within the specified range. 

For example, 

77 STUDENT-DEGREE. 

88 BTECH VALUE IS ONE. 

88 MTECH VALUE IS TWO. 

IF BTECH THEN . . . 

ELSE . . . 

The Condition name condition in IF statement is replaced with function 
call BTECH{). The function BTECH() returns boolean value true or false 
depending up on the value of the variable STUDENT-DEGREE. 


21 



Negated simple condition 

A Simple condition can be negated by a NOT operator. 

The conversion rule for tin* Siini)le condition is: 

NOT siinpit'- condition 
is replaced with 
! simple- condition 

Compound condition 

A Compound condition is formed by connecting conditions with logical op- 
erators. 'Fhe only logical opt'ralors available in COBOL are AND and OR. 

The conv«’rsion rule for the Compound condition is: 

condifion-1 |AND | OH } condition-2 ... 
is replaced with 

condition- 1 | kk | || } condition-2 ... 

4.2.5 Move statement 

1’he Move statement is used to copy data from one data item to another data 
item, 'fhe receiving or s<’n<ling operand of Move statement can be either an 
elenmiitary data item or a group data item. When both the operands are 
<*lementary data items then the data movement is called Elementary move 
else it is calbHl Group mov<*. 

'i'he conversion rule for the Elementary Move statement is: 
l'lu‘ Move statement is replaced either by an assignment statement or by a 
string copy statement or by a library function depending on the type of the 
sending and receiving fields. 

For example, 

MOVE A TO B. 

If both A and B are of alphanumeric type then the above 
MOVE statement is replaced witii 
strncpy(B, A, operand-1); 
where operand- 1 is size of the data item B. 
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If A is of numeric type and B is of alphanumeric type then 
the above MOVE statement is replaced with 

MoveSqlC( “format of A", A, “format of B”, B); 
where MoveSqlC is a library function. 

If both A and B are of numeric type then the above statement 
is replaced with 
B = A: 

(’OB()I, supports integer and float types witii variables sizes, while C 
supports th<*se with pretiefined size.s. In COBOL, when a value larger than 
size of data item is niove<l to it then truncation occurs. The above semantics 
tif COBOL can be siniulat<‘d in (’ by providing a library function wdiich 
truncates the valin* pro}>erly, if need<*d. 

\Vh<ui data is moved to I'ditable data item, it gets edited according to 
description sptrified in its picture class. In C we can simulate the same by 
calling a library function. 

I Ik' conversion rule for the Croup Move statement is: 

The Grouf) Mo\'<* statement is replaced with following statements 

• ('ontents of the sending fields of the Move statement are copied in to 
t(‘niporary variable t«’in{)S<il(’; 

• Data is n«m*<l to the receiving fields of the Move statement from temp- 

S<jKc, 


4.2.6 Arithmetic statements 

The arithmetic statements that are supj)ortcd by COBOL are Add state- 
ment, Subtract statement. Divide statement, Multiply statement and Com- 
pute statement. 

Add statement 

Tlie Add stat ement is u.sed to add one or more numeric operands and store 
the sum. 

The conversion rules for the Add statement are: 
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• Fortnat I: 

ADI) operand-] |,op<Tand-2] ... TO opcrand-3 
/,operaii<l-4 J . . . . 
is rephoed with 

operand-^ ■+= operand-l [+ opcraiid-2 / ...; 
/operand--! += op<Tand-I /-f c)pcrand-2 / / 


• f'onnttl Ih 

ADD <ip«“iand 1 /.tiperand-'i/ . .. CJIVING o}>erand-3 
/operand Aj . . . . 
i.s repla<«‘d with 

oprjand .3 op<-iaiHl-l /f op<Tand-2y ...; 

/i>p<-ian<i 1 operand- 1 operand-'i/ . . . ; / 


Subtract statement 

TheSuldrart sfafeinenf is used to subtract one or sum of two or more numeric 
operatnis fianii one or mor<‘ Jtunieric operands and store the result. 

The <<»nversioii rules for tlie Subtract statement are: 

• Foniiat I: 

Sl’H'rii.Af’i OperaiKhl /.<rperand-2/ ... FROM operand-3 
/operand-!] ... . 
is replaced with 

operand 3 -i- operand-! / •+ operand -27 ...; 

/o|>erand--l -■= operaiul-l /-f opcrand-2 ]•■■;] 


• Format 2: 

SUB'l’R ACT operand-! /operand-2 ] ... FROM operand-3 
/operand-! J ... GIVING operand-5 [ , operand-6 J . .. 
is replaced with 

operaiid-5 = operand- 1 /■+ operand-2 ] ...-operand-3 
/-operand-! J . ..] 

/operand-G = operand- 1 /-F operand-27 ... -operand-3 
/-operand-47 ■ - - ; / 
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Multiply statement 

I’Ik' Mnltij)Iy stateiju'iit is \is<‘(l to multiply a numeric operand by another 
and store the result. 

I'he conversion rules fur the Multiply statement are: 

• Format /: 

Mil,’! IPIA’ uix'raiul-l operand-2 /,o]>erand-3 ] .... 

is replaied with 

ujunaud 2 * ujieiaud 1; 

/uperaiHl d * u]n-rami 1; j 


• Format 2: 

M r i.I il’L^’ t>]ieraiid l B\" op<Tand-2 /,operand-3y ... 
(il\’L\(i uperaud-’l /, oi)erand-57 ... • 
is repla<<Hl with 

upcrand-1 - t>i>eran<l-‘2 * operand- 1; 

/operand 5 uperand-3 * operand-l; ] 


Divide statement 

'I’he Divide stat«‘inent i.s u.sed to divide one or more numeric operands by a 
mmwu'ie op<*rand and store the result. 

'I'he conversion rtiles for the Divide statement arc: 

• Format /: 

DIX'IDE operand- 1 INTO operand-2 /, operand-3 ] ... . 
is replaced with 

operand-2 f~ operand-1; 

/operaud-3 j -- operand-1; ] 


• Format 2: 

DIVIDE operand- 1 INTO operand-2 /, operand-3 ] ... 
GIVING operand-4 /, opcrand-5/ ... . 
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is r<‘j>l«r<'<3 with 

ijjMTaiHi 4 2 / oj)«Taiui-l; 

(opcraiu! r> - ojicraiui-'i /operand-];] 


• Format 

(jpriaiKl 1 <)|><Tand-2 GIVING operand-3 

/.oj»‘ran<l 1 ] . . . . 
is replaced with 

opeiaiid 3 <>]*<-iand 1 / <>]>eraiHl-2; 

/iipeiaiid I <iiM“i.)iid 1 / operaiid-’i:/ 


• Foi unit -I : 

Mjieiaiid 1 H\' opc'taini 2 (II\'1NC« opeiand-3 
HKMAINDKR operand J 
is jepla< ed with 

operand s ujceiand-l / <)perand-2: 
operand t operand 1 ‘X <>p<'rand-2: 

C-omputc statemejit 

Till* ('onipule statement is tis«‘d to assign to one or tnore mnncric operands 
the value' of aiithiiK'ti* expression. 

The (tinversion tidi* for the (’onijnite slaletn<*nt is: 

(’OMPT ri’’, opc'iaud I [,<*perand-2) ... - arithni<'tie-<'xpression. 

Ls repjaeed with 

operand- 1 ' aritlunc't ie t'xpie.ssiun; 

/operajid-2 -= arithineti< -e.xpression;/ 


4.2.7 Soquence control statements 

These stati'inents arc* used to all<*r the flow of control. 



Perform statement 

The Perform stHtenieiit is usrtl fo transfer control to one or more paragraphs 
and rc'tnrn the* control to curniit paragraph after th<*ir execution. Perform 
.statc'uwnt is replat <■«! either hv a function call or by a Goto statement de- 
ptniding on whether the paragraph is converted to a function or a block. In 
a typical ('OBOI. program a paragraph can be executed by any of the three 
ways mentioiK'tl earlier. paragraph cannot be converted into a function, if 
the ('OliOL program tontains both Goto and Perform statements. Because 
in such piogiams we can leplaie the Perforin statement by a function call, 
hut there is no ei|uivah n! statement for tin* Goto stateiiKUit. One solution 
to this piohleui is a.s follows. 

If the ( ’OHOI, pii*giani tioes not have* a Goto statement then we convert 
the paragraph to a fiiui lion. If the COBOL program contains both Goto 
and PerfoiiH statements then wemnvtut the paragraph to a lilock. 

The conxersion rules for the P«*rfoini statement when it is replaced with 
a fniK lion call are; 

• Fonnaf I: 

PKHFOUM para name 1 THRP para-name-2 
is reph'H ed with 

para name 1 ( ): 

par.i name 2( ); 

• Furtiiut 2: 

PKHl’OHM |»ara name 1 TilHr para-uaTnc‘-2 o])eraud TIMES 
is replacc'd xvith 

{ int i — {opcTHiul > 0)?operand:0; 
whi!e(i- -) | 

para-iiaine-1 (): 

para-na!nc*-2(); 

} 

1 


• Format ii: 

PEHFOHM para- name- 1 THRU para-name-2 
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UNTIL condition, 
is replaced with 
wi»ile(! condition) { 
para- name- 1(); 

para-namc-2U; 

1 


• Forviat 

ri'.HFOHM para iiaim-.I THHU para- namc-2 VARYING 
o{>erand I FROM opptaiid-2 BY opcrand-3 
UNTIL coiidit bn-l 

/AF I'F.H (ipcrai 1(1-1 FROM (>i)<'rand-5 opcrand-6 
UNTIL ( oiMiitu>n-2y 

/AF'i'KH uperaiid-T FiJOM oi)<“rand-8 B\’ operand-9 
UN'I'IL condilion-3/ 

is K'placed willi 

for(op<'rand-l = opcraiKl-2; !condition-l ; 
operand- 1-F= operand-S) 

/f(>r(operand-l = opeta»<F5; Icondit ion-2; 

operand (>p(*rand-G) ] 

/f<>r(operaiid-7 = oj>crand-8; !c<)ndition-3; 

(iperand 7+~ oporand-9)/ { 
para name 1( ); 

para namc-2( ); 

} 

I'ho conversion rule for the Perforin statement when it is replaced with a 
Goto statement is: 

The Perform statement returns control to the current paragraph implicitly 
after executing the specified paragraph- One can simulate the semantics of 
the Perform statement in C’ by following the rules specified below. 

• For every Perform statement generate a new label and a number. Gen- 
erated number is used to identify label. 
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• Replace the Perform statement by a function call to push the gen- 
erated label number into stack and the Goto statement to the block 
corresponding to the paragraph specified in it. 

• Place the generated label next to the Goto statement. 

• At the end of each block place a function call, which checks whether 
control is transferred to that block by Perform statement, and transfers 
control to the Perform handler if it is so. 

• Place the Perform handler at the end of program which transfer controls 
to the statement next to label by examining the contents of the top 
ek-ment of the stark. 

PushSqR'{label-no); 

goto para-name: 

Sql(Llabel-no: ; 


para- name: { 

if( lsPrfrmStintSqlC( )) 
goto PrfrmllndlSql; 

} 

/* Perform handler*/ 

PrfrniHndlSqlC :{ 

switch(PopSqlC()) { 
case label-no: 
goto SqlCJabel-no; 

} 

PushSqlC: This function Pushes the label-no into stack. 
IsPrfrmStmt: This function checks whether. control is 
transferred to the paragraph bj' the Perform statement. 
PopSqlC: This function pops the top element of the stack. 
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Goto staionient 

Th<* Goto KtatoiiKMit is usod to transfer control from one paragraph to an- 
other. 

J'he conversion rule for the Goto statement is: 

• Formai /: 

GOTO para- name, 
is replaied with 
goto para- name; 

• Foriiidf 

(JOTO para nam<‘ 1 /,para-name-27 ... 

DFPKNDIXG O.N operand-1. 

is replaced with 

swit(h(oii«'rami 1 ) | 

< a.se ] ; 

goto para- nanu*- 1; 

/case 2: 

goto para naine-2: 

j 


If stat<‘njent 

'I’he If statiunent evahiate.s the condition and the subsequent actions of object 
program rlepeml.s up on the value of tlie ctmdition. 

'l'h<* conversion rui<*s for the If statement are: 

• For ill at 1 : 

IF coiuiition THEN statements, 
is replaced with 
if( condition) { 
statements; 

} 

• Format 2: 

ii’ condition THEN statcinents-1 
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ELSE statnn<*ntf<-2. 
is n'placfd with 
if(condition) { 

SliltCITlCllts-1 

} 

els<‘ ■{ 

statements- 2 

} 

Stop statement 

The Slop statement is us<'d to t<Tminate theexeeution of the object program. 
'1‘lje <unv<Msion rule f<*i the St<»]» stat<‘ineiit is: 

STOP HEN. 

is replaced with 
exit{()); 

Call statement 

The Cal! stat<-inent is useil to transfer control from one object program to 
another. 

'I'he conversion rule for ('all statement i.s: 

(’AIvL prt>g name CSINO ojauaml-l /,operan(i-2 ] ... 
i.s replaced with 

prog name{paranu-ter ! /,parainet<‘r-2y . . . ); 

\Vher<‘ parameter I is ad<lr<*ss of the operand- 1. 


Exit Program statement 

The Exit Program statennuit is used to terminate the execution of the object 
program and return the control to the calling program. 

The conver.sion rule for t!ie Exit program statement is: 

Exrr PHOCRAM 
is replaced with 
r<*tuni; 
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4.2.8 Input-Output statements 

Tht* Input -out put statements are used to read or write the data items from 
input or output deviees. 

Accept statement 

The Aeeept stat<-ment is used It) scan data for the specified data items. 

'I'he conversion rules for the Accept statement arc: 

• Ftninat I: 

1 operand- 1, 
is repla< «-d with 

s( anf( ‘'fuimaf". i>iiramet<“r-l ); 

W hen’ p.iiamefei 1 is the address for operand- 1 . 

• l oniiat 

A(’('Kl‘ r operand- 1 FROM DATE, 
is replaced with 

Dat aS«il(’(teinp.Stjl(’); 
ss<atif(t«*nipSqK\ "format”, parameter-1); 

W’hen' jjarajtH’ter- 1 is tin* aridress for ()|)erand-l and DataSqlC 
is a lihiary fmu ti«>ii to Ret tlx* enrrent date. 

• Foniiat 

ACCKF l Operand I FROM DAY. 
is rep!af«‘«l with 
I)ayS<jl('(teiupS<jl('): 
s.seanf(t«‘mpS<{l{’, "format'*, parameter- 1 ); 

Where parameter- 1 is the ad(lre.ss for operand-1 and DaySqlC 
is a library function to get the current day. 

• Forvuti 4 ■ 

A(’(’KFr operand-! FROM TIME, 
is rc’)»!ac<‘d with 

'riineS<|l( '{temp.Sql(’); 
shcanf(tempSqK.’, ‘“format”, parameter-l); 

U’here parameter- 1 is the address for operand-1 and DataSqlC 
is a library function to get the current time. 
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Display stntemrnt 

Tli<* Display stat<‘tn<‘nt is us<-<l to tiisplay th<* specified data items on the 
console. 

The conveisioii rule fi>r the Display statement is; 

DlSi’I.A^ operaml 1 /.oj»erand-2/ ... 
is replaceti vvitli 

print f( "foniiat" , {)perand-l /.<»perand-2j ...); 


4.2.9 Fil<’ niaiiipulation statements 

In (’OBOl . a tih’ « an he act«'>sc<! in any of tlir<‘e nuxies - secpicntial, ran- 
<ioni oi ti>ii.iniir. If a file is accessed se(iueiitia!ly. then we can simulate it 
in (’ with einl»edd«'«l SQI. hy <le< hiring cnr.sor for the table corresponding to 
the file. Olheiwise, w<‘ have to use the SQL query with key as the selection 
< riterioii. tile witli relative organization is handled by including a field in 
tln“ conesimiicling tahh* that gives relative record number. The following sec- 
tions list the restructuring rules fur the main file access statements available 
in ('OHOI.. I’ur (he file descriptions anti tabh' definitions refer to Appendix 
A. 

Open sfatenicnt 

The Open stat<*meijt is used to initiate file processing. 'J'he Open statement 
i.s repl.it eil with the following statements, only if tlu' file specified in the Open 
.statement is a(ie.*.se(l setjuentially ainl is opem'd in the input mode. 

• {‘ursur definition for the table corresponding to file. 

• SQI. statenwuit to open the cursor. 

i’br examjde, 

OPK.N INPrr <’AHI)S-1.\’. 
is repl.it eii with 
K.XllC SQI. declare CARD.IN 
cursor for 
s<‘I<*ct 
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< Ar<i niiiiH-. 
raril -stirrl , 
fiirtl.rity 
frt>ni ciiril in; 

KXK<’ SQl, oiM'ii (’AHl)S.lN; 

Close stnteinent 

'I’hc Clo''*' s!at<-ii»*iit is usni to teiininate the file processing. The Close 
stalenient is n'plaieti with SQi, (’iitsr statement, only if cursor is defined for 
the talile r*tuesp*iiniii4' tu file spei ijiril in tiic Open .statement. 

I'\>i «*xample 

Ci.OSI C.AHDS 1 N‘. 

is replaced witli 

KXK(’ SQl. ch.se (WHDS IX; 


Read statement 

'i’he Head .slatfuiieiit is used ti> read a retord from the file, if cursor is defined 
fur the talde ctirK-spondiiig tti the file s]>ecified in the R(“ad statement then 
ih<* Hea<l statement is replaced with an SQl. cpiery. which reads a tuple from 
the cursor. 

For example, 

HKAI> (’A HI) IN. 

is replaced with 

KXKC SQI. fetch ( ‘AH I) IN into 
;(’A!{l),NA.MK. 

:<’AHl>..STHKi:r. 

;(’ARl).(TrV 


If curst>r is not <le(ine«i for tij<* table corresponding to the file specified in 
tin* Head statement then the Head statement is replaced with an SQL query, 
which reads a tuple frmn the table. 
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For example, 

READ CARDJN. 
is replaced with 
EXEC SQL 
select 

card -name, 
card -Street, 
card -city 
into 

:CARD.NAME, 

:CAHD^1'REET. 

:(’AHD.CITV 
from card -in 

wliere carcLname = :CAHD.NAME; 

Write statement 

The Write statement is used to write a record into a file. The Write state- 
ment is replaced with an SQL query, which inserts a tuple into the table 
corresponding to the file. 

For example, 

WHITE CARD, 
is replaced with 

EXEC SQL insert into cardin 

( 

card-name, 
card -Street, 
card-citv 
) 

values ( 

:CARD-NAME, 

:CARD-STREET, 

rCARD.CITY 

); 
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Rewrite statement 

The Rewrite statement is used to replace a record in the specified file. 

If cursor is defined for the table corresponding to the file specified in the 
Rewrite statement then the Rewrite statement is replaced with a SQL query, 
which updates the current row pointed by cursor. 

For example, 

RFAVRITE CARD.IN. 
is replaced with 

EXEC SQL update cardJn 
set 

card.name = :C.^H1).N.-\.ME, 
canLstreet = ALMiD.S'l'REET, 
card.fity = :('.AR1).C1TV 
where current of CARD.IN; 

If cursor is not defined for the table corresponding to the file specified in 
the Rewrite statement then the Rewrite statement is replaced with an SQL 
query, which updates a tuple in the table. 

For example, 

REWRITE CARDJN. 
is replac<‘(l with 

EXEC SQL update card.in 
set 

card.name = :CARD-NAME, 
card.streot = :CARD.STREET, 
card.city = :CARD-CITY 
where cardmame = rCARDJNAME; 

Delete statement 

The Delete statement is used to delete a record from the specified file. 

If cursor is defined for the table corresponding to the file specified in the 
Delete statement then the Delete statement is replaced with an SQL query, 
which deletes current row pointed by the cursor. 
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For example, 

DELETE CARDJN. 
is replaced witli 

EXEC SQL (]el<‘te from carclJn 

where current of CARDJN; 

If cursor is not defined for the table corresponding to the file specified 
in the Delete statement then the Delete statement is replaced with a SQL 
query, which deletes a tuple from the table. 

For exainph', 

DFLKTK C.AHDJN. 

is re]>liu etl wit h 

KXhX’ SQL delete from cardJn 
wh<Te cardJn = :(\AHD.!N; 

Sort and Merge statement 

The Sort statement is used to sort records on a set of specified keys and store 
the sorted records. 

Th<* general syntax for sort command is 
SOH'F fih'-name-l 

ON { ASC'KNDINC 1 DESCENDING } KEY 
data-naine-1 /,data-naine-27 ... 

USING file-uame-2 /’,file-name-37 .. . 

(JiVlN(J fil<‘-nam<*-4. 

Conversion rule for the Sort statement is: 

• Declare cursor for each input file of sort command. 

• Read the records from each cursor and insert the read record into the 
table corresponding to the output file. 

• If cursor is defined for the table corresponding to the output file spec- 
ified in tlie Sort statement, then it is defined with order by clause on 
the sort condition. 
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The Morgc statement is used to merge one or more sequential files on a set 
of specified keys and write the merged records in the output file. Conversion 
rule for the Merge statement is similar to the conversion rule used for the 
Sort statement. 

4.2.10 Unification issue 

Unification results in a single integrated view of data. Due to this a record 
fiehl can be unified to more than one table field. If this happens the file 
acce.ss stat<“m<‘nls have tt) he niodifK'd appropriately. This modification is 
necessary 1><*( aus<' the fil<* acc<‘ss slat(Mn<'nts arc replaced with SQL queries 
which refer to l(l>. 

For example. 

File description for ('AHD.IN is 
01 CAHl). 

02 ADDHKSS PICTURE IS X(S0). 

Unyd<‘f for the CARD.IN file is 
ADDRESS r { 

CAHD.NAME s 25 u, 

<'AHl)-S'rRKET s 25 u, 

(’ARDAdTV s 30 u, 

} 

Acconiing to the ah(m> mentioned conversion rule for the Read statement 
th<* following .statenx'iit is replaced with 
HEAD ('ARD..IN. 

EXEC SQL fetch CARDJN into 
:CARD-NAMESqlCl, 

:CARD_STREETSqlC2, 

:CARD.CITYSqlC3 

1 


The above SQL query reads data in to sub-fields CARD_NAMESSqlCl, 
CARI).STHEETSqlC2, and CARD.CITYSqlC. But the COBOL Read state- 
ment reads data in to record field CARD_ADDRESS. This will lead to in- 
consistency. The above problem is solved by placing statements, which move 
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data from sub-fidds to the appropriate record field, after every Read state- 
ment. The information regarding the appropriate record field can be obtained 
from Unydef. For examine, we generate the following statements after the 
above Head statement. 

s})ri!itf(tem]>SqlC, “format", CARD_NAMESqlCl , 
CAHr).STREETSqlC2, CARD.CITYSqlC3); 
sscanf(tempSqKb “format", CARD.ADDRESS); 

Similarly, oiu’ ha.s to mow data in to the appropriate fields before every 
Write and Hewritr* statements. 

4.2.11 Procedure division 

Rrueedure division of a COBOL prograni is made up of paragraphs. Con- 
v<*rsion rul<‘ for th<‘ Brocednre division depends on whether paragraph is 
converUHl to a function or a block. 

'Lhe gi'iieral syntax for the Procedure division of COBOL program is 
Procedure division header. 

Proce<iur<‘ division body. 

Proce<lure division header is replaced with main or function name de- 
pemliiig on whelln'r CSINCJ phrase is sj)ecified in the Procedure division 
Ix'ader or not . 

• Format !: 

PROCEDURE DD ISION. 
is replact'd with 
main( ) 

• For'tnat 2: 

PROCEDURE DIVISION USING data-name-l 
/,data-naine-2 ] . . . 
is replaced with 

program_name(data-name-l / ,data-name-2 ] ... ) 

Where program Jiame is the name of program specified in the 
Identification division of COBOL progi'am. 
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Th<* g<'n«*ral format for t!i<- Procedure division body is 
program- header 
paragrapli-name. 

/ senlences ] 

Conversion rule for tlie paragraph when it is converted to a function is: 
program- heaiier. { 

paragraph-name(); 

} 

Void paragraph naiin-() | 

/.M'lit elit es ] 

) 

(’onv«-rsion rule for the paragrapli wlien it converted to a block is: 
program- header { 

paragraph naiiK*: { 

/sent<*nces J 
if( FrfrmStmtSqK’O) 
goto PrfrmHndlrSqlC; 

} 

} 

Where PrfrmStmtS<}lC < h<‘cks whether control is transferred to the paragraph 
by t!i<‘ P<‘rform statement. 
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Chapter 5 

SQLC: A Workbench for 
Re-engineering 


III this fhaptiT wf (ii-scriht* the tools provided by SQLC. 


5.1 SQLC 

SQLC proviiics an fiivinnmicnt to re-eugiueer e.xisling systems, implemented 
in COUOI. to a relational platform. 

It proviile.s following fools to the user: 

• I’ai.ser 

• Cuifyer 

• Converter 

• Slieer 

• iiidafioiHT 

Parser. I nifvi’r ami Convert<'r are lused to migrate COBOL programs to the 
target (mvironmeiit. Slieer and Belationer displays high level abstractions of 
the subject sysf<*in. 
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5.1.1 Parser 


Parser builds the data view as seen by each program. The data view as 
seen by each program is described by file descriptions. Parser takes COBOL 
program as input and outputs file descriptions [3]. 



5.1.2 Uiiifyer 

Unifier unifies different data views into a single integrated data view. It takes 
file descriptions extracted by the parser as input and outputs data model of 
the subject system in an intermediate form named Unydef [3]. 



5.1.3 Converter 

Converter transforms COBOL program to C with embedded SQL program 
by applying restructuring rules. It takes the recovered data model and the 
COBOL program as input and outputs C with embedded. 
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5.1.4 Slicer 

Slicer displays the Program dcpejidence graph (PDG) of the subject system. 
The PDG specifies the dependencies between the programs of subject system. 
The main advantage of PDG is i-eusability. If we are interested in only some 
programs of subject system, then PDG is helpful in finding out w'hich are all 
the programs to be re-engineered. 

PDG can be constructed with a single pass over the source code. Each 
node of the graph corresponds to a program or a subroutine. The edges of 
PDG represent dependencies. There will be an edge from node ’a’ corre- 
sponding to program ’A’ to node ’b’ corresponding to program ’B’, if pro- 
gram A calls program B. Once the PDG has been constructed, finding out 
the various programs which are dependent on a given program is straight for- 
ward; starting from the node in the graph which corresponds to the program 
which we are interested in, generate the transitive closure of those nodes by 
following dependence edges. 

5.1.5 Relatioiier 

Relationer provides two features to the user. 

1. Display and modify the fields of relations of the subject system. 

2. Convert the table to a C file. 

Changing the names of fields is to make them more readable. We illustrate 
a scenario which will result in field names that are not readable. In the 
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subject system, the data view as seen by each program may be different. 
One such case is, same data item has different names in different programs. 
When these fields are unified in Unification, the name of the field is decided 
randomly. This may lead to names which are not readable. Using this 
tool user can change the names of the fields of relation to make them more 
readable. 

We are treating all files in COBOL as relations. But this assumption is 
not always true. For example a file in COBOL can be used to store reports. 
Such files cannot be treated as tables. By using this tool the user can specify 
which table.s are to be treated as files. This information is used by the 
converter which generates file access statements instead of embedded SQL 
statements. 
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Chapter 6 

Characteristics of 
Re-engineered system 


This chapter describes various characteristics of re-engineered system and 
also outlines the test suite followed to test the restructuring rules. 

6.1 Characteristics of Re-engineered system 

The re-engineerd system is evaluated on the following characteristics. 

• System life: The existing COBOL systems have become outdated with 
current technology. By re-enginering the subject system to a relational 
platform we are extending the features of a RDBMS environment to 
it. This will increase the life of the subject system. The re-engineered 
programs may not be readable as we are using a fully automated pro- 
cedure for re-engineering the COBOL programs to target environment. 
But typically the re-engineerd code is considered as a black box and is 
not maintained further, so the readability is not a issue. 

• Data model', The data model of the re-engineered system is represented 
by relations and is not dependent on the application programs. Also, 
the data view as seen by each program is same. 

• Extensibility: A Relational platform supports many features like report ' 
generator, query language etc., which are not available in conventional 
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COBOL. These facilities decrease the amount of effort spent by the user 
in order to extend the features of the subject system. For example, a 
simple query eliminates the need to write a separate program. Also 
report generator aids the user in preparing customized reports which is 
a very tedious process in COBOL. Therefore the re-engineered system 
is easily extensible. 

• Code length: The re-engineered code is typically longer than the 
COBOL program. 

- The COBOL file access statements specify only the name of the 
file to be accessed. But in C with embedded SQL, in addition to 
table name corresponding to the file, we have to specify the fields 
of the table. 

- The COBOL language statements are at a higher level compared 
to C language statements. As a result some of the COBOL state- 
ments are restructured to more than one C statement. For exam- 
ple, the Divide statement in COBOL can specify division for more 
than one operand which is not possible in C. 

— The language conversion is not straight forward, so the re- 
engineered code may contain calls to library functions to simu- 
late semantics of COBOL. For example, In COBOL when data 
is moved to editable data item it gets edited according to the de- 
scription in its picture class. As C does not provide such a feature, 
we have to explicitly call a library function to edit the data. 

- The re-engineered object code is larger than COBOL object code 
as re-engineered object code by default includes code for dis- 
tributed access, security check and crash recovery. 



COBOL program 

source code 

(lines) 

C with embedded 

SQL source code 

(lines) 

COBOL program 

object code' 

(kBytes) 

C with embedded 

SQL object code 

(kBytes) 

43 

86 

2540 

504259 

55 

172 

3308 

508406 

59 

177 

3600 

508528 

78 

153 

3984 

508651 

85 

188 

3872 

507419 

89 

182 

3888 

507077 

105 

176 

4012 

507357 

386 

1206 

12376 

535467 


• Execution time: 


COBOL program 

source code 

(lir^es) 

C with embedded 

SQL source code 

(lines) 

COBOL program 

execution time 

(secs) 

C with embedded 

SQL execution time 

(secs) 

43 

86 

1.1 

1.5 

55 

172 

1.3 

1.9 

58 

177 

1.4 

2.3 

78 

1 

153 

1.8 

2.4 

85 

188 

2.3 

2.6 

89 

182 

2.3 

2.8 

105 

176 

2.5 

3.1 

386 

1206 

5.2 

6.3 


A re-engineered program typically takes longer time to execute than a 
COBOL program. But execution time should not be taken into con- 
sideration as the re-engineered program runs on top of a relational 
platform which provides facilities like security, crash recovery and dis- 
tributed access. The above table shows execution time for various 
COBOL program and corresponding C with embedded SQL. The exe- 
cution time is the average time for 20 runs. 


6.2 Test suite 

la this s<*ction we outline the procedure followed to test the restructuring 
rules. 
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For testing the restructuring rules, the COBOL statements can be cat- 
egorised as Arithmetic and Move statements, Output statements. Sequence 
control statements and File access statements. 

• Arithmetic and Move statements: The Arithmetic and Move state- 
ments modify the contents of the data items. The conversion rules for 
these statements were tested by comparing the contents of the data 
items after execution of the COBOL statement and the corresponding 
C statement. 

• Output statements: These statements output the contents of the data 
items on the console. The conversion rule for these statements were 
tested by redirecting the the output of both the COBOL program hav- 
ing these statements and the corresponding C with embedded SQL into 
temporary files and doing a file comparison of these files. 

• Seque7ice control statements These statements alter the flow of control. 
The conversion rules for these statements were tested by compiling the 
COBOL program which contains these statements and the correspond- 
ing C with embedded SQL with debugging option and checking the 
control flow by tracing these programs using a debugger. 

• File access statements These statements modify the data stored in the 
files. The conversion rules for these statements were tested by exe- 
cuting the (lOBOL program which consists these statements and the 
corresponding C with embedded SQL and checking whether the data 
present in the data files and tables is same or not. 
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Chapter 7 
Conclusions 


In this thesis, we have discussed the conceptual framework used in re- 
engineering existing file based COBOL systems to a relational platform and 
the various restructuring rules used for transforming COBOL programs to C 
with embedded SQL. 

Our main aim has been to develop SQLC, a workbench, which provides 
an environment to re-engineer information systems which are implemented 
in COBOL. VVe have designed and implemented Converter, which transforms 
the COBOL program into a C with embedded SQL using restructuring rules. 
W'e have also constructed the PDG of the subject system which is useful in 
finding out the reusable components of the subject system. The application 
of tlu' framework to the existing COBOL systems thus far has demonstrated 
that it is a practical method for re-engineering. The framework has to be 
tested against larger systems. 

Th<* limitations of Converter are; 

• It assumes that COBOL table data items are not present in the file 
description of a COBOL program. 

• It does not handle the variable length records. 

• It assumes that all the data items in a record are used in the program. 
Future v^^ork 

• By augmenting data flow analysis in Converter, we can remove the data 
items that are not used in the program. 
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• The Goto statements distort the comprehension of the COBOL pro- 
gram. Finding a method which removes Goto statements would be 
very useful. 

• Converter may be integrated in a case tool environment so that it can 
access the design information of the system. This will increase the 
functionality of the Converter. 
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Appendix A 
Example program 


This appendix i)resonts two COBOL program which have different data views 
and their equivalent C with embedded SQL programs created by SQLC. 


Program 1 


IDENTIFICATION DIVISION. 

PROGRAH-ID. READ-RECORDS. 

ENVIRONMENT DIVISION. 

CONFIGURATION SECTION. 

INPUT-OUTPUT SECTION. 

FILE-CONTROL. 

SELECT CARD-IN ASSIGN TO •’CARD^RECS” . 

DATA DIVISION. 

FILE SECTION. 

FD CARD-IN 

DATA RECORD IS CARD. 

01 CARD. 

02 NAME PICTURE IS X(25). 

02 STREET PICTURE IS X(25). 

02 CITY PICTURE IS X(30). 

WORKING-STORAGE SECTION . 

01 END-OF-DATA-INDICATOR PICTURE IS XXX VALUE IS "NO*’. 
PROCEDURE DIVISION. 

MAIN-LOGIC. 

OPEN OUTPUT CARD-IN. 

DISPLAY ‘‘INSERTING RECORDS INTO FILE CARD-IN" 
PERFORM WRITE-A-CARD 

UNTIL END-OF-DATA-INDICATOR IS EQUAL TO "YES". 
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CLOSE CARD-IN. 

STOP RUN. 

WRITE-A-CARD. 

DISPLAY ••ENTER NAME:”. 

ACCEPT NAME. 

DISPLAY ••ENTER STREET: ••. 

ACCEPT STREET. 

DISPLAY '‘ENTER CITY:'* 

ACCEPT CITY. 

WRITE CARD. 

DISPLAY •‘ENTER YES TO END READING RECORDS” 
ACCEPT END-OF-DATA-INDICATOR. 



Program 2 


IDENTIFICATION DIVISION. 

PROGRAM-ID. PRINT-RECS. 

ENVIRONMENT DIVISION. 

CONFIGURATION SECTION. 

INPUT-OUTPUT SECTION. 

FILE-CONTROL. 

SELECT CARD-IN ASSIGN TO “CARD-RECS” . 

DATA DIVISION. 

FILE SECTION. 

FD CARD-IN 

LABEL RECORDS ARE OMITTED 
DATA RECORD IS CARD. 

01 CARD. 

02 ADDR PICTURE IS X(80). 

WORKING-STORAGE SECTION. 

01 END-OF-DATA-INDICATOR PICTURE IS XXX VALUE IS “NO*’. 
PROCEDURE DIVISION. 

MAIN-LOGIC. 

OPEN INPUT CARD-IN 

DISPLAY "PRINTING RECORDS FROM FILE CARD-IN" 
PERFORM READ-A-CARD. 

PERFORM PRINT 

UNTIL END-OF-DATA-INDICATOR IS EQUAL TO "YES". 
CLOSE CARD-IN. 

STOP RUN. 

READ-A-CARD. 

READ CARD-IN RECORD AT END 

MOVE "YES" TO END-OF-DATA-INDICATOR. 

PRINT. 

DISPLAY ADDR. 

PERFORM READ-A-CARD. 
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Given below is a table recoverd by SQLC from the above COBOL programs. 


Table card_recs 

( 

card.naone char(26), 
card_street char(26), 
card_city char(3l) 

); 
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PrograB 1 


•include <»tdio,h> 

•include <string.h> 

• include *'ex.21.h** 

ElfD_OF_FILE (long)lOO 
TRUE 1 

•d«fin« FALSE 0 
#d«Tine MAX_REC_SIZE 100 
EXEC SQL include »qlca; 
char teBipSqlcCMAX_REC_SIZE3 ; 
char tempSqlCl [MAX_REC_SIZE] ; 

/• Data Diwiaion entries declarations ♦/ 

/•Host Variable declarations lor file CARD-IN*/ 

EXEC SQL begin declare section; 
char CARD_NAHEC25 + l3 ; 
char CARD_STREET[25 + l3 ; 
char CARD_CITYC30 + 1] ; 

EXEC SQL end declare section; 

/•Working Storage entries declarations ♦/ 
char EHD_0F_DATA_IKDICAT0RC3 + l] ; 

void InitWSEntriesO { 

strncpy (EHD_OF_DATA_ISDICATOR,"NO" ,3) ; 

> 

iBain( ){ 

InitWSEntriesO: 

EXEC SQL whenever sqlerror continue; 

IprintKstdout, "Please wait connecting to INGRESW); 
EXEC SQL connect anara ; 

/•Check for connect error*/ 

if (sqlca. sqlcode < 0) { 

fprintf (stderr, "Error y.ld connecting to database , 
sqlca. sqlcode ); 

exit(l) ; 

} 

HAIH.LOGICO: 

WRITE_A.CARD(); 

> 

void 

MAIH.LOGICO { 
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IprintKstdout, "XnlNSERTIHG RECORDS INTO FILE CARD-IK"); 
vhile(!( strcmp(END_OF_DATA_INDICATOR, "YES") == 0 )) { 
WRITE_A_CARD(); 

} 

EXEC SQL commit; 

EXEC SQL disconnect; 
exit(O) ; 


void 

WRITE_A^CARD() { 

fprintf (stdout, “XnENTER NAME:"); 

1 scanf (stdin , •‘y,25s" , CARD„NAME) ; 
fprintf (stdout, "\nENTER STREET:"); 
f scanf (stdin, "y.25s" , CARD.STREET) ; 
fprintf (stdout, "\nENTER CITY:"); 
f scanf (stdin, "XSOs" , CARD.CITY) ; 

EXEC SQL insert into card_recs 

( 

card^name , 
card.street , 
card_city 
) 

values ( 

:CARD.NAME, 

:CARD.STREET, 

•.CARD.CITY 

): 

fprintf (stdout, "\nENTER YES TO END READING RECORDS"); 
fscanf (stdin, "‘/.as", END_OF_DATA_INDICATOR) ; 
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Prograa 2 


# include <stdio.h> 

# include <string.h> 

# include “ex.22.h’* 

# define END.OF.FILE (long) 100 

# define TRUE 1 

# define FALSE 0 

# define MAX.REC.SIZE 100 
EXEC SQL include sqlca; 
char tempSqlCCMAX^REC^SIZE] ; 
char tempSqlCl [MAX_REC_SIZE3 ; 

/>♦' Data Division entries declarations ♦/ 

/*Host Variable declarations for file CARD-IN*/ 

EXEC SQL begin declare section; 
char CARD^ADDR[80 + 1]; 
char CARD_NAMESqlCl[25 + 1]; 
char CARD^STREETSqlC2C25 + l] ; 
char CARD.CITYSqlCS [30 + 1]; 

EXEC SQL end declare section; 

/♦Working Storage entries declarations ♦/ 
char END.0F„DATA^INDICAT0R[3 + 1]; 

void InitWSEntriesO { 

strncpy(END.0F.DATA^INDICAT0R/'N0”,3); 

} 

main( ){ 

InitWSEntries ( ) ; 

EXEC SQL whenever sqlerror continue; 
fprintf(stdout, "Please wait connecting to INGRES\n*'); 
EXEC SQL connect amara ; 

/♦Check for connect errors/ 
if (sqlca. sqlcode < 0) { 

fprintf (stderr , "Error V.ld connecting to database ", 
sqlca. sqlcode ); 
exit(l) ; 

} 

MAIN^LOGICO; 

READ.A.CARDO ; 

PRINK ) ; 

} 
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void 

MAIH^OGICO i 

/♦Cursor declarations for file CARD-IN*/ 

EXEC SQL declare CARD.IN 
Cursor for 
select 

card.name , 
card^street , 
card_city 
^roin card_recs; 

exec SQL open CARD.IN; 

fprintf (stdout, "\nPRINTING RECORDS FROM FILE CARD-IN"): 
READ_A_CARD() ; 

whiled ( strcmp(END_OF_DATA_INDICATOR, "YES") == 0 ) ) { 
PRINTO : 

} 

exec SQL close CARD.IN; 

EXEC SQL commit ; 

EXEC SQL disconnect; 
exit(O); 


void 

read_a_card() { 

exec SQL letch CARD.IN into 
: CARD.NAMESqlCl , 

: CARD_STREETSqlC2 . 

: CARD_CITYSqlC3 

I 

sprint! (tempSqlC, "*/.-25sy.-25sy.-30s" , CARD.NAMESqlCl, 
CARD^STREETSqlC2 , CARD_CITYSqlC3) ; 
strcpy(CARD_ADDR, tempSqlC) ; 

/♦Check for end of table ♦/ 
if(sqlca.sqlcode == END_OF_FILE) i 

strncpy(END OF.DATA INDICATOR, "YES" ,3) ; 

> 

> 

void 

PRINTO { 

fprintf (stdout , '’\n%80s'' ,CARD_ADDR) ; 

EEAD_A_CARD(); 
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Appendix B 
Example program 


This appendix presents a sample COBOL program and its equivalent C with 
cmibedded SQL program created by SQLC. 

IDENTIFICATION DIVISION. 

PROGRAM-ID. UPDATE-STUD-DATA. 

ENVIRONMENT DIVISION. 

INPUT-OUTPUT SECTION. 

FILE-CONTROL. 

SELECT CRS-FILE ASSIGN TO "COURSE” 

ORGANIZATION INDEXED 
ACCESS MODE RANDOM 
RECORD KEY IS CRS-ID. 

SELECT STUD-FILE ASSIGN TO "STUDENT" . 

SELECT ENROL-FILE ASSIGN TO "ENROLL" . 

DATA DIVISION. 

FILE SECTION. 

FD CRS-FILE. 

01 CRS-REC. 


02 CRS-ID 

PIC 

X(6). 

02 CRS-NAME 

PIC 

X(40). 

02 INSTR 

PIC 

X(25). 

02 UNITS 

PIC 

9. 

» STUD-FILE. 



STUD-REC. 



02 ROLL-NO 


PIC 9(7). 

02 STUD-NAME 


PIC X(25) 

02 ADDR 


PIC X(30) 

02 UNITS-DONE 


PIC 99. 

02 CPI 


PIC 9V99. 
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FD ENROL-FILE. 

01 ENROL-REC. 

02 EN-ROLL-NO PIC 9(7). 
02 EN-CRS~ID PIC X(6). 


02 

GRADE PIC 

X. 

WORKING-STORAGE SECTION. 

77 

WS-ROLL-NO 

PIC 9(7) . 

77 

WS-CRS-ID 

PIC X(6). 

77 

WS-UNITS-REGD 

PIC 99. 

77 

E-O-F 

PIC 9 VALUE 0 

88 

STUD-FILE-END 

VALUE 1. 

88 

CRS-FILE-END 

VALUE 2. 

88 

ENROL-FILE-END 

VALUE 3. 

77 

FLAG 

PIC 9. 

88 

OVER VALUE 1 . 



PROCEDURE DIVISION. 

MAIN-PARA. 

OPEN INPUT STUD-FILE. 

OPEN INPUT CRS-FILE. 

OPEN OUTPUT ENROL-FILE. 

PERFORM PROCESSING 
UNTIL STUD-FILE-END. 

CLOSE STUD-FILE. 

CLOSE CRS-FILE, 

CLOSE ENROL-FILE. 

STOP RUN, 

PROCESSING. 

PERFORM GET-STUDENT. 

IF NOT STUD-FILE-END 
MOVE 0 TO FLAG 

PERFORM REGISTER-COURSES UNTIL OVER. 

DISPLAY WS-UNITS-REGD. 

GET-STUDENT. 

READ STUD-FILE RECORD AT END 
MOVE 1 TO E-O-F. 

REGISTER-COURSES. 

DISPLAY “CRSNO:". 

ACCEPT WS-CRS-ID. 

IF WS-CRS-ID = ’0’ 

MOVE 1 TO FLAG 
ELSE 

MOVE WS-CRS-ID TO CRS-ID 
READ CRS-FILE 

COMPUTE WS-UNITS-REGD = WS-UNITS-REGD + UNITS 
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MOVE ROLL-KO TO EN -ROLL-NO 
MOVE WS-CRS-ID TO EN-CRS-ID 
MOVE TO GRADE 
WRITE ENROL-REC. 
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Given below are the tables recoverd by SQLC from the COBOL program. 

Table course 

( 

crs_rec_crs_id char (7) not null, 
crs_rec_crs_naine char (41) , 
crs_rec_instr char(26), 
crs_rec_units integer 
); 

Table enroll 

( 

enrol_rec_en_roll_no integer, 
enrol_rec_en_crs_id char(7) , 
enrol_rec_grade char(2) 

); 

Table student 

( 

stud_rec_roll_no integer, 
stud_rec_stud_name char(26) , 
stud_rec_addr char(31) , 
stud_rec_units_done integer, 
stud_rec_cpi float 
); 
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# include <stdio.h> 

# include <string.h> 

# include **a.cb.h" 

# define END.OF^FILE (long) 100 

# define TRUE 1 

# define FALSE 0 

# define MAX.REC.SIZE 100 
EXEC SQL include sqlca; 
char tempSqlCCMAX.REC.SIZE] ; 
char tempSqlClCMAX^REC^SIZE] ; 

/’♦'Data Division entries declarations*/ 

/♦Host Variable declarations for file CRS-FILE*/ 
EXEC SQL begin declare section; 
char CRS.REC„CRS.ID[6 + l] ; 
char CRS_REC^CRS.NAME[40 + 1]; 
char CRS_REC_INSTR[25 + l] ; 
int CRS^REC.UNITS; 

EXEC SQL end declare section; 

/♦Host Variable declarations for file STUD-FILE*/ 
EXEC SQL begin declare section; 
int STUD3EC.R0 LL.no ; 
char STUD.REC.STUD.NAMEC25 + 1]; 
char STUD.REC.ADDRC30 + 1]; 
int STUD.REC.UNITS.DONE; 
float STUD.REC.CPI ; 

EXEC SQL end declare section; 

/♦Host Variable declarations for file ENROL-FILE*/ 
EXEC SQL begin declare section; 
int ENROL.REC.EN.ROLL.no; 
char ENR0L.REC.EN.CRS.ID[6 + 1]; 
char ENROL.REC.GRADECI + 1] ; 

EXEC SQL end declare section; 

/♦Working Storage entries declarations*/ 
int WS.R0 LL.no ; 
char WS.CRS.IDC6 + 1] ; 
int WS.UNITS.REGD; 
int E.O.F; 
int FLAG ; 

void InitWSEntriesO { 

E.O.F = 0; 
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> 


int OVERO { 

if{ FLAG == 1 ) { 
return TRUE; 

> 

return FALSE; 


int ENROL_FILE_END() { 
if( E_0_F == 3 ) ■[ 
return TRUE; 

> 

return FALSE; 


int CRS_FILE_END() { 
if( E_0_F == 2 ) { 
return TRUE; 

} 

return FALSE; 


int STUD^FILE.ENDO { 
ii( E.O.F == 1 ) { 
return TRUE; 

} 

return FALSE; 


main( ){ 

InitWSEntries ( ) ; 

EXEC SQL whenever sqlerror continue; 

fprintf (stdout/’Please wait connecting to INGRES\n”); 

EXEC SQL connect amara ; 

/♦Check for connect error*/ 
if (sqlca. sqlcode < 0) { 

fprintf (stderr , ’’Error V.ld connecting to database ", 
sqlca . sqlcode ); 
exit(l) ; 

} 

MAIN^PARAO ; 

PROCESSINGO; 

GET.STUDENTO ; 
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REGISTER_COURSES() ; 

> 

void 

MAIK_PARA() { 

/♦Cursor declarations for file STUD-FILE*/ 
EXEC SQL declare STUD .FILE 
cursor for 
select 

stud.rec.roll.no , 
stud.rec.stud.name , 
stud.rec.addr , 
stud.rec.units.done , 
stud.rec.cpi 
front student; 

EXEC SQL open STUD.FILE; 
whiled (STUD.FILE.ENDO )) { 

PROCESSINGO; 

> 

EXEC SQL close STUD.FILE; 

EXEC SQL commit ; 

EXEC SQL disconnect; 
exit (0) ; 

> 


void 

PROCESSIKGO i 

GET.STUDENTO ; 

if(! STUD.FILE.ENDO ) { 

FLAG = 0; 

whiled (OVERO )) { 

REGISTER.COURSESO; 

} 

} 

fprintf (stdout , •'\n'/.2d" ,WS.UHITS_REGD) ; 


void 

GET.STUDENTO { 

EXEC SQL fetch STUD.FILE into 
:STUD_REC_ROLL_1IO, 

: STUD.REC.STUD.NAME . 

: STUD.REC.ADDR, 
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: STUD.REC^UNITS.DONE , 
:STUD_REC_CPI 

/♦Check for end of table ♦/ 
if (sqlca. sqlcode == END_OF_FILE) { 
E.O.F = 1; 

> 


void 

REGISTER^COURSESO { 

fprintf (stdout , "\nCRSN0: “) ; 
fscanf (stdin/'y.6s'‘, WS_CRS_ID); 
if( strcmp(WS^CRS_ID. "0") == 0 ) { 

FLAG = 1; 

} 

else { 

strncpy ( CRS^REC.CRS.ID , WS_CRS.ID , 6 ) ; 

EXEC SQL select 

crs_rec_crs_id, 
crs_rec_crs_naine , 
crs^rec.instr , 
crs.rec_units 

into 

:CRS3EC_CRS.ID, 

:CRS.REC^CRS.NAME, 

:CRS3EC^INSTR, 
rCRS^REC.UNITS 
from course 

where crs_rec_crs_id = :CRS3EC_CRS_ID; 
WS^UNITS.REGD = WS.UNITS.REGD + CRS.REC.UNITS 
AllignSqlC('*y.2d'* , AWS^UNITS.REGD) ; 
ENROL.REC.EN^ROLL.NO = STUD^EC.ROLL.NO ; 
strncpy (ENROL^REC_EN_CRS^ID , WS^CRS^ID , 6 ) ; 
strncpy (ENROL^REC_GRADE/'X*‘ , 1) ; 

EXEC SQL insert into enroll 

( 

enrol„rec_en_roll_no , 
enrol_rec„en.crs_id, 
enrol^rec.grade 
) 

values ( 

: ENROL.REC.EN.ROLL^NO , 

: ENROL^REC.EN.CRS^ID , 
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